Payment transaction process employing dynamic account expiry and dynamic token verification code

ABSTRACT

A method includes receiving a request for payment credentials. The request indicates an account from which payment for a transaction is to be made. A payment token is looked-up that corresponds to the indicated account. Dynamic expiry data and a dynamic token verification code are generated. As a response to the request, the looked-up payment token, the generated dynamic expiry data and the generated dynamic token verification code are transmitted.

BACKGROUND

FIG. 1 is a block diagram that illustrates a conventional payment system100.

The system 100 includes a customer device 102 by which a user 103accesses an e-commerce server 104 via the internet 105. The customerdevice 102 may be any type of computing device usable to allow access tothe internet, and runs a browser program (not separately shown) toenable interaction between the customer device 102 and the variousresources available via the internet. The customer device 102 may be,for example, a personal computer, a laptop computer, a tablet computeror a mobile-browser-equipped smartphone or other mobile device. Thee-commerce server 104 is typically a server computer operated by or onbehalf of a merchant to host an online store/shopping website and toallow virtual visits to the website from customer devices. Thee-commerce server 104 also operates to handle online-shoppingtransactions, typically funded by a payment system account owned by theuser 103. In an online shopping transaction, the user 103 operates thecustomer device 102 to select one or more items for purchase, thenelects to enter a checkout phase of the transaction, in whichinformation that identifies the user's payment system account isprovided to or accessed by the e-commerce server 104.

A computer 108 operated by an acquirer (acquiring financial institution)is also shown as part of the system 100 in FIG. 1. The acquirer may be afinancial institution that provides payment account acceptance servicesto the merchant that operates the e-commerce server 104. The acquirercomputer 108 may operate to receive a transaction authorization requestmessage (“authorization request”) for the online shopping transactionfrom the e-commerce server 104. The acquirer computer 108 may route theauthorization request via a payment network 110 (sometimes also referredto as a “card network”) to the server computer 112 operated by theissuer of the payment account that was specified during the checkoutphase of the online shopping transaction. A transaction authorizationresponse message (“authorization response”) generated by the paymentaccount issuer server computer 112 may be routed back to the e-commerceserver 104 via the payment network 110 and the acquirer computer 108.

One well known example of a payment network is referred to as the“Banknet” system, and is operated by Mastercard InternationalIncorporated, which is the assignee hereof.

The payment account issuer server computer 112 may be operated by or onbehalf of a financial institution (“FI”) that issues payment accounts toindividual users and/or other entities. For example, the payment accountissuer server computer 112 may perform such functions as (a) receivingand responding to requests for authorization of payment accounttransactions to be charged to payment accounts issued by the FI; (b)engaging in payment transaction clearing operations; and (c) trackingand storing transactions and maintaining account records.

The components of the system 100 as depicted in FIG. 1 are only thosethat are needed for processing a single transaction. A typical paymentsystem may process many purchase transactions (including simultaneoustransactions) and may include a considerable number of payment accountissuers and their computers, a considerable number of acquirers andtheir computers, and numerous merchants and their e-commerce servers.The system may also include a very large number of payment accountholders, who engage in online shopping transactions.

As is well known to those who are skilled in the art, a typical paymentsystem like that shown in FIG. 1 may also handle numerous face to facepurchase transactions at the point of sale in retail stores and otherestablishments. In a typical such transaction (not illustrated), thecustomer may present a payment card or other payment-enabled device(e.g., a payment-enabled mobile device) to a point of sale (POS)terminal. The POS terminal is operated by the merchant (or merchant'semployee) to read payment account information from the card or devicepresented by the customer. An authorization request may originate fromthe POS terminal for routing to the account issuer, and theauthorization response may be routed back to the POS terminal from theaccount issuer.

In some e-commerce transactions, the user enters the PAN (primaryaccount number) for his/her payment card account during the checkoutphase of interaction between the customer device and the e-commerceserver. In other arrangements, there may be a “card-on-file” with thee-commerce server, so that the user does not have to enter his/her PAN.To enhance security, and help to protect the PAN from being interceptedby a wrongdoer, in a card-on-file arrangement the user's payment accountmay be represented by a payment token, which is a character string thatserves as a replacement for the PAN during part of the transactionprocess. For example, the payment token may be dedicated for use only ine-commerce transactions with the merchant in question.

The present inventors have now recognized an opportunity to furtherenhance the security and convenience of e-commerce transactions.

BRIEF DESCRIPTION OF THE DRAWINGS

Features and advantages of some embodiments of the present disclosure,and the manner in which the same are accomplished, will become morereadily apparent upon consideration of the following detaileddescription of the disclosure taken in conjunction with the accompanyingdrawings, which illustrate preferred and exemplary embodiments and whichare not necessarily drawn to scale, wherein:

FIG. 1 is a block diagram that illustrates a conventional paymentsystem.

FIG. 2 is a block diagram that illustrates a payment system providedaccording to aspects of the present disclosure.

FIG. 3 is a block diagram that illustrates a computer system that mayperform a role in the system of FIG. 2.

FIG. 4 is a block diagram that illustrates another computer system thatmay perform a role in the system of FIG. 2.

FIG. 5 is a simplified block diagram of a customer device that mayperform a role in the system of FIG. 2.

FIG. 6 is a flow chart that illustrates a process that may be performedin the system of FIG. 2 according to aspects of the present disclosure.

DETAILED DESCRIPTION

In general, and for the purpose of introducing concepts of embodimentsof the present disclosure, as part of an e-commerce transaction, theuser may request a transaction-specific set of payment credentials froma remote payment services computer. In response to the request, thepayment services computer may look up a payment token that points to anaccount that the user has selected to use for the current transaction.The payment services computer may also engage in a cryptographic processor processes to generate dynamic expiry data and a dynamic tokenverification code. The payment service computer may send the paymenttoken, the dynamic expiry data and the dynamic token verification codeto the user as a set of transaction-specific payment credentials. Theuser may in turn provide the set of payment credentials to the merchantfor inclusion in an authorization request and downstream verification ofthe dynamic expiry data and the dynamic token verification code.

With an arrangement of this kind, the desirable security goal is met ofeffectively submitting a transaction-specific token that can be verifiedduring payment system processing and that cannot be reused ifintercepted by a wrongdoer.

FIG. 2 is a block diagram that illustrates a payment system 200 providedaccording to aspects of the present disclosure.

As in the system of FIG. 1, a user 103 is shown operating a customerdevice 202, so as to interact with an e-commerce server 204 via theinternet 105. An acquirer 108 provides the e-commerce server (merchant)204 with access to a payment network 110 a. The system also includes anaccount issuer 112, to which the merchant's authorization request isultimately routed via the payment network 110 a. In accordance withaspects of the present disclosure, the system 200 further includes apayment services computer 206. Via in-app or internet communication 208,the customer device 202 interacts with the payment services provider 206to obtain a set of payment credentials, as described herein.

The two dot-dash lines 210 linking the payment services computer 206 tothe payment network 110 a are intended to imply the possibility orpossibilities that (a) the payment services computer 206 is under commonoperation with the payment network 110 a; and/or (b) the paymentservices computer is closely associated with, in frequent communicationwith, and/or at least partially overlaps with computing resourcesemployed in operating the payment network 110 a.

As was the case with the system as depicted in FIG. 1, FIG. 2 only showscomponents required for handling a single transaction. In a practicalembodiment of the system 200, there may be numerous e-commerce servers,and customer devices, a large number of merchants' banks/acquirers andissuers, and potentially also a number of payment service computers. Thesystem 200 may also handle transactions at the point of sale, and so mayinclude many items of POS equipment like those referred to above. Stillfurther, the system 200 may include a very large number of customerpayment devices, such as cards, fobs, payment-enabled mobile devices,etc., for use in initiating transactions at the point of sale.

FIG. 3 is a block diagram that illustrates an embodiment of the paymentservices computer 206 shown in FIG. 2.

Referring now to FIG. 3, the payment services computer 206 may, in itshardware aspects, resemble a typical server computer and/or mainframecomputer, but may be controlled by software to cause it to function asdescribed herein. For example, the payment services computer 206 may beconstituted by commercially available server computer hardware and/or bycloud-based computing resources.

The payment services computer 206 may include a computer processor 300operatively coupled to a communication device 301, a storage device 304,an input device 306 and an output device 308. The communications device301, the storage device 304, the input device 306 and the output device308 may all be in communication with the processor 300.

The computer processor 300 may be constituted by one or moreconventional processors. Processor 300 operates to executeprocessor-executable steps, contained in program instructions describedbelow, so as to control the payment services computer 206 to providedesired functionality.

Communication device 301 may be used to facilitate communication with,for example, other devices (such as customer devices). For example,communication device 301 may comprise numerous communication ports (notseparately shown), to allow the payment services computer 206 tocommunicate simultaneously with a large number of other devices,including communications as required to simultaneously handle numerousrequests for payment credentials.

Input device 306 may comprise one or more of any type of peripheraldevice typically used to input data into a computer. For example, theinput device 306 may include a keyboard and a mouse. Output device 308may comprise, for example, a display and/or a printer.

Storage device 304 may comprise any appropriate information storagedevice, including combinations of magnetic storage devices (e.g., harddisk drives), optical storage devices such as CDs and/or DVDs, and/orsemiconductor memory devices such as Random Access Memory (RAM) devicesand Read Only Memory (ROM) devices, as well as so-called flash memory.Any one or more of such information storage devices may be considered tobe a computer-readable storage medium or a computer usable medium or amemory.

Storage device 304 stores one or more programs for controlling processor300. The programs comprise program instructions (which may be referredto as computer readable program code means) that containprocessor-executable process steps of the payment services computer 206,executed by the processor 300 to cause the payment services computer 206to function as described herein.

The programs may include one or more conventional operating systems (notshown) that control the processor 300 so as to manage and coordinateactivities and sharing of resources in the payment services computer206, and to serve as a host for application programs (described below)that run on the payment services computer 206.

The programs stored in the storage device 304 may also include asoftware communications interface 310 that programs the processor 300 tofacilitate communications between the payment services computer 206 andcustomer/user devices.

The storage device 304 may also store a payment credentials requesthandling application program 312. The payment credentials requesthandling application program 312 may program the processor 300 to enablethe payment services computer 206 to handle numerous requests forpayment credentials as described herein.

The storage device 304 may also store, and the payment services computer206 may also execute, other programs, which are not shown. For example,such programs may include a reporting application, which may respond torequests from system administrators for reports on the activitiesperformed by the payment services computer 206. The other programs mayalso include, e.g., database management software, device drivers, etc.

The storage device 304 may also store one or more databases 314 requiredfor operation of the payment services computer 206.

FIG. 4 is a block diagram that illustrates an embodiment of a computer401 that performs at least some functionality required for operation ofthe payment network 110 a. The computer 401 will accordingly be referredto as the “payment network computer.” The payment network computer 401may resemble the above-described payment services computer 206 in termsof hardware architecture and/or constituent components. Accordingly, thepayment network computer 401 may include a computer processor 400operatively coupled to a communication device 402, a storage device 404,an input device 406 and an output device 408. The communications device402, the storage device 404, the input device 406 and the output device408 may all be in communication with the processor 400.

Processor 400 operates to execute processor-executable steps, containedin program instructions described below, so as to control the paymentnetwork computer 401 to provide desired functionality.

Storage device 404 stores one or more programs for controlling processor400. The programs comprise program instructions (which may be referredto as computer readable program code means) that containprocessor-executable process steps of the payment network computer 401executed by the processor 400 to cause the payment network computer 401to function as described herein.

The programs may include one or more conventional operating systems (notshown) that control the processor 400 so as to manage and coordinateactivities and sharing of resources in the payment network computer 401,and to serve as a host for application programs (described below) thatrun on the payment network computer 401.

The programs stored in the storage device 404 may also include asoftware communications interface 410 to facilitate data communicationsbetween the payment network computer 401 and computers operated bytransaction acquirer banks. In addition, the storage device 404 maystore a software communications interface 412 to facilitate datacommunications between the payment network computer 401 and computersoperated by account issuer banks.

The storage device 404 may also store a transaction handling applicationprogram 414. The transaction handling application program 414 mayprogram the processor 400 to enable the payment network computer 401 tohandle numerous payment account system transactions includingverification of payment credentials as described below.

Still further, the storage device 404 may store a transaction clearingapplication program 416. The transaction clearing application program416 may program the processor 400 to enable the payment network computer401 to handle clearing of payment account system transactions betweenissuer and acquirer banks.

The storage device 404 may also store, and the payment network computer401 may also execute, other programs, which are not shown. For example,such programs may include a reporting application, which may respond torequests from system administrators for reports on the activitiesperformed by the payment network computer 401. The other programs mayalso include, e.g., database management software, device drivers, etc.

The storage device 404 may also store one or more databases 418 requiredfor operation of the payment network computer 401.

FIG. 5 is a simplified block diagram of an example of the customerdevice 202 shown in FIG. 2. In this example embodiment, the customerdevice 202 is illustrated as a mobile device such as a smartphone.

The customer device 202 may include a housing 503. (In cases where thecustomer device 202 is a desktop computer, the customer device 202 mayinclude several housings including the “tower” housing, the keyboardhousing, etc.)

The customer device 202 further includes a processor/control circuit506, which is contained within the housing 503. Also included in thecustomer device 202 is a storage/memory device or devices (referencenumeral 508). The storage/memory devices 508 are in communication withthe processor/control circuit 506 and may contain program instructionsto control the processor/control circuit 506 to manage and performvarious functions of the customer device 202. Programs/applications (or“apps”) that are stored in the storage/memory devices 508 arerepresented at block 510 in FIG. 5, and may be accessed to program theprocessor/control circuit 506. In view of its pertinence to theteachings of this disclosure, a browser program is shown separately fromthe programs/apps 510 and is represented by block 511. In the same vein,a payment app 512 is depicted separately from the other programs/apps510 Physical and/or software aspects of the device user interface,including input/output (I/O) devices, are represented at block 513 inFIG. 5.

As is typical for computing devices, the customer device 202 may includecommunications components as represented by block 514. Thecommunications components 514 allow the customer device 202 to engage indata communication with other devices. For example, the communicationscomponents 514 may support mobile communications functions that includevoice and data communications via a mobile communications network (notshown). The data communication capabilities of the customer device 202may allow for online browsing sessions and interactions with webpagesvia the browser 512 and/or may support “in-app” communication sessions.

From the foregoing discussion, it will be appreciated that the blocksdepicted in FIG. 5 as components of the customer device 202 may ineffect overlap with each other, and/or there may be functionalconnections among the blocks which are not explicitly shown in thedrawing.

FIG. 6 is a flow chart that illustrates a process that may be performedin the payment system 200 according to aspects of the presentdisclosure.

At 602 in FIG. 6, the user 103 operates his/her customer device202/browser 512 to engage in an online shopping transaction viainteraction between the browser 512 and the e-commerce server computer204 (FIG. 2). It is assumed that the user 103 selects one or more itemsfor purchase in the transaction, and proceeds to the checkout phase(block 604) of the online shopping transaction.

At 606 in FIG. 6, it is determined that the merchant/e-commerce server204 supports a payment method, as described below in more detail, inwhich dynamic expiry data and a dynamic token verification code arecoupled with a payment token to form a set of payment credentials. Step606 may occur via an interaction between the mobile browser 511 (FIG. 5)and the e-commerce server 204.

At 608 in FIG. 6, it is determined that the payment app 512 (FIG. 5)supports the payment method referred to above in connection with step606. This determination may occur via an interaction between the mobilebrowser 511 and the payment app.

At 610, the payment app is assumed to be selected by the user from amonga number of different payment mechanisms that may be supported by themerchant.

At 612, the user is presented with an opportunity to select from among anumber of different accounts belonging to the user, with the selectionto indicate which account is to be used for the current transaction. Insome embodiments, the accounts available for selection may include adeposit account maintained at a bank and belonging to the user. Otheraccount options available for selection may include credit cardaccounts, debit card accounts, prepaid card accounts, etc. It is furtherassumed at 612 that the user selects one of the available accountoptions.

At 614, the customer device 202, via operation of the payment app 512,may interact with the payment services computer 206 so as to transmit tothe payment services computer 206 a request for payment credentials. Itmay be assumed that the payment services computer 206 receives therequest for payment credentials. The request for payment credentials mayinclude an indication of the account that the user selected at 612.

At 616, the payment services computer 206 may look up a previouslycreated payment token that has been associated ahead of time with theselected account. As used herein and in the appended claims to “look up”includes the payment services computer 206 accessing a token databasethat it stores and/or communicating with a token service provider (notshown) to retrieve the result of a mapping between the selected accountand a payment token previously assigned to represent the selectedaccount.

At 618, the payment services computer 206 generates dynamic expiry datato be associated for the current transaction with the payment tokenlooked up at 616. The expiry data is “dynamic” in the sense that it ischanged from transaction to transaction, rather than being fixed (for aperiod of a few years) as is the conventional expiration date generallyassociated with a PAN or payment token.

At 620, the payment services computer 206 generates a dynamic tokenverification code to be associated for the current transaction with thepayment token looked up at 616. The dynamic token verification code isto take the place of a “fixed” code such as a CVC that is customarilyassociated with a PAN or payment token. The dynamic token verificationcode is “dynamic” in the sense that it is changed from transaction totransaction, rather than being fixed (for a period of a few years) as isa conventional CVC associated with a PAN.

In some embodiments, the steps 618 and 620 may be accomplished via oneor more cryptographic processes performed by the payment servicescomputer 206. The payment token looked up at 616 may be one of theinputs of the cryptographic process or processes. One or more items oftransaction data (i.e., data that indicates one or more attributes ofthe current transaction) may also be an input or inputs of thecryptographic process. Examples of transaction data may includetransaction number, transaction amount and/or transaction date and/ortime.

According to one example cryptographic process for accomplishing steps618 and 620, the payment services computer 206 may concatenate thepayment token with one, two or more numeric items of transaction dataand then may digitally sign the resulting numeric string with a secretcryptographic key. The resulting digital signature is a second numericstring from which the dynamic expiry data and the dynamic tokenverification code may be derived. For example, the first three digits ofthe second numeric string may be used as the dynamic token verificationcode. The next four or more digits of the second numeric string may besubjected to a transformation that produces a four-digit number thatsatisfies the constraints required to mimic a valid card expirationdate. The resulting four-digit number may be employed as the dynamicexpiry data. Based on the above description, those who are skilled inthe art will recognize that other cryptographic processes mayalternatively be used to generate the dynamic expiry data and thedynamic token verification code, using the payment token and one or moreitems of transaction data as inputs.

Referring again to FIG. 6, at 622, the payment services computer 206 maytransmit the payment token looked up at 616, the dynamic expiry datagenerated at 618 and the dynamic token verification code generated at620 to the customer device 202 as the requested set of paymentcredentials. It may be assumed that the result of step 622 is that thepayment app 512 in the customer device 202 receives that set of paymentcredentials.

At 624, the payment app 512 may pass the payment credentials to themobile browser 511 in the customer device 202. At 626, the mobilebrowser may control the customer device 202 to transmit the paymentcredentials to the e-commerce server 204. It may be assumed that thee-commerce server 204 receives the payment credentials transmitted to itat 624.

At 628, the e-commerce server 202 (i.e., the merchant) may assemble atransaction authorization request message (authorization request) in astandard format. The payment token may be inserted in the paymentaccount number field of the authorization request format. The dynamicexpiry data may be inserted in the card expiration date field of theauthorization request format. The dynamic token verification code may beinserted in the (for example) CVC field in the authorization requestformat. The authorization request may also include transaction data suchas transaction amount and merchant i.d., including the one or more itemsof transaction data used by the payment services computer 206 togenerate the dynamic expiry data and the dynamic token verificationcode.

Block 630 in FIG. 6 represents routing and processing of theauthorization request. This may include routing the authorizationrequest via the acquirer 108 to the payment network 110 a. As part ofthe processing of the authorization request, the payment networkcomputer 401 may detokenize (or obtain detokenization of) the paymenttoken, and also may verify the dynamic expiry data and the dynamic tokenverification code. The verification processing may include duplicatingthe process by which the payment services computer 206 generated thedynamic expiry data and the dynamic token verification code using thepayment token and transaction data as inputs.

With the PAN or other account number data produced by detokenization,the payment network computer 401 may route the authorization request tothe account issuer 112. As forwarded from the payment network computer401 to the account issuer 112, the authorization request may contain oneor more indications that the payment network computer 401 had verifiedthe payment credentials.

At 632, the transaction authorization response message may be generatedby the account issuer 112 and routed to the merchant. It may be assumedfor purposes of this discussion that the authorization request and thecondition of the user's account satisfied the issuer's requirements forapproving the transaction, and that the authorization responseaccordingly indicates approval of the requested transaction.

At 634, the merchant (e-commerce server 204) may send a message to thecustomer device 202 to indicate that payment processing for thetransaction has been completed. Fulfillment of the transaction by themerchant may then proceed in due course.

With a payment process as described herein, a highly secure mode ofaccount identification may be incorporated in an e-commerce transaction.The desirable goal of what is in effect a transaction-specific set ofpayment credentials is achieved in a manner that is convenient for theuser. Although the payment token itself may be reused, the token itselfwould be of little value to a wrongdoer, if one should intercept it,because the payment token is used only in combination withtransaction-specific dynamic expiry data and a dynamic tokenverification code. The latter two elements of the payment credentialsare transaction-specific and are changed for every transaction. Becauseof the security provided by cryptographic processes, the notionalwrongdoer would likely find it impossible to generate valid expiry dataand a valid token verification code in order to re-use the token,assuming the same were to be intercepted. Consequently, there is reducedconcern over any possible data security breach that might occur withrespect to the merchant's systems.

There will now be a further discussion of aspects of the processillustrated in FIG. 6, particularly in regard to transactionauthorization and clearing. According to one clearing mode of operation,payment settlement occurs in real time. According to another clearingmode of operation, traditional payment system clearing processes takeplace.

The traditional clearing mode will be discussed first. In this mode,transaction authorization occurs after the user has engaged in selectionof an online purchase and has selected a bank account as the paymentinstrument. Authorization request processing proceeds from the merchantvia the acquirer and the payment network to the account issuer. It willbe understood that payment credentials were obtained by the user andprovided to the merchant as described above in connection with FIG. 6.As the authorization response is processed at the payment network, thedynamic elements of the payment credentials are verified. Fraud servicesmay also be performed by the payment network, along with detokenization.

Assuming approval of the authorization request, an ACH (automatedclearing house) processor (not separately shown) associated with thepayment network may enrich the authorization request with paymentinstruction details (e.g., “from” the user's bank account and “to” theuser's bank holding account) and converts the authorization request inISO 8583 format to ISO 20022 format before sending the authorizationrequest to the user's bank.

The ACH processor converts the authorization response from the user'sbank from ISO 20022 to ISO 8583 before sending the authorizationresponse back to the acquirer. The ACH processor also matches theauthorized and cleared transactions before sending them to the user'sbank.

The ACH processor sends payment instructions to the user's bank to debitthe user's bank account and to credit the user's bank holding account.The ACH processor provides clearing and reconciliation files to theuser's bank to support clearing and reconciliation. A settlement accountmanagement system (not separately shown) sends the settlement advice toa payment network settlement bank (not shown) after reconcilingauthorization and clearing files. The user's bank settles with thepayment network settlement bank, which then settles with the acquirerbank.

The real time clearing mode will next be discussed. In this mode,transaction authorization occurs after the user has engaged in selectionof an online purchase and has selected a bank account as the paymentinstrument. Authorization request processing proceeds from the merchantvia the acquirer and the payment network to the account issuer. It willbe understood that payment credentials were obtained by the user andprovided to the merchant as described above in connection with FIG. 6.As the authorization response is processed at the payment network, thedynamic elements of the payment credentials are verified. Fraud servicesmay also be performed by the payment network, along with detokenization.

Assuming approval of the authorization request, an ACH (automatedclearing house) processor (not separately shown) associated with thepayment network may enrich the authorization request with paymentinstruction details (e.g., “from” the user's bank account and “to” theuser's bank holding account) and converts the authorization request inISO 8583 format to ISO 20022 format before sending the authorizationrequest to the user's bank.

The ACH processor converts the authorization response from the user'sbank from ISO 20022 to ISO 8583 before sending the authorizationresponse back to the acquirer. The ACH processor also appends themerchant's bank account information to the payment request.

The ACH processor sends the payment request to the user's bank to debitthe user's bank account and credit the merchant bank account. The user'sbank clears the transaction with a real-time payment bank (not shown),which in turn clears the transaction with the acquirer bank. The user'sbank settles with the real-time payments bank, which settles with theacquirer bank.

As used herein and in the appended claims, the term “computer” should beunderstood to encompass a single computer or two or more computers incommunication with each other.

As used herein and in the appended claims, the term “processor” shouldbe understood to encompass a single processor or two or more processorsin communication with each other.

As used herein and in the appended claims, the term “memory” should beunderstood to encompass a single memory or storage device or two or morememories or storage devices.

The flow charts and descriptions thereof herein should not be understoodto prescribe a fixed order of performing the method steps describedtherein. Rather the method steps may be performed in any order that ispracticable, including simultaneous performance of at least some stepsand/or omitting one or more steps.

As used herein and in the appended claims, the term “payment card systemaccount” includes a credit card account or a deposit account that theaccount holder may access using a debit card. The terms “payment cardsystem account” and “payment card account” and “payment system account”and “payment account” are used interchangeably herein. The term “paymentcard account number” includes a number that identifies a payment cardsystem account or a number carried by a payment card, or a number thatis used to route a transaction in a payment system that handles debitcard and/or credit card transactions. The term “payment card” includes acredit card or a debit card.

As used herein and in the appended claims, the term “payment cardsystem” refers to a system for handling purchase transactions andrelated transactions. An example of such a system is the one operated byMastercard International Incorporated, the assignee of the presentdisclosure. In some embodiments, the term “payment card system” may belimited to systems in which member financial institutions issue paymentcard accounts to individuals, businesses and/or other organizations.

Although the present disclosure has been set forth in connection withspecific exemplary embodiments, it should be understood that variouschanges, substitutions, and alterations apparent to those skilled in theart can be made to the disclosed embodiments without departing from thespirit and scope of the disclosure as set forth in the appended claims.

What is claimed is:
 1. A method comprising: receiving a request forpayment credentials, the request indicating an account from whichpayment for a transaction is to be made; looking up a payment token thatcorresponds to said account; generating dynamic expiry data and adynamic token verification code; and responding to the request bytransmitting the looked-up payment token, the generated dynamic expirydata and the generated dynamic token verification code.
 2. The method ofclaim 1, wherein said transmitted payment token, dynamic expiry data anddynamic token verification code collectively uniquely correspond to saidtransaction.
 3. The method of claim 2, wherein said generating stepincludes a cryptographic process that has the looked-up payment token asan input.
 4. The method of claim 3, wherein said cryptographic processhas transaction data as another input, said transaction datacorresponding to at least one attribute of said transaction.
 5. Themethod of claim 1, further comprising, after said responding step:receiving a transaction authorization request message, the transactionauthorization request message containing said payment token, saiddynamic expiry data and said dynamic token verification code.
 6. Themethod of claim 5, further comprising, after receiving said transactionauthorization request message: verifying said dynamic expiry data andsaid dynamic token verification code.
 7. The method of claim 1, whereinthe receiving, looking-up, generating and responding steps are performedby a payment services computer.
 8. The method of claim 7, wherein thepayment services computer is operated by an operator of a paymentaccount system.
 9. The method of claim 1, wherein the indicated accountis a deposit account maintained at a bank.
 10. A method comprising:sending a request for payment credentials for a transaction; andreceiving the requested payment credentials, the received paymentcredentials including a payment token, dynamic expiry data and a dynamictoken verification code; wherein the payment token, the dynamic expirydata and the dynamic token verification code collectively uniquelycorrespond to said transaction.
 11. The method of claim 10, furthercomprising: submitting the received payment credentials to a merchantassociated with the transaction.
 12. The method of claim 11, wherein thesending, receiving and submitting steps are performed by a mobiledevice.
 13. An apparatus comprising: a processor; and a memory incommunication with the processor, the memory storing programinstructions, the processor operative with the program instructions toperform functions as follows: receiving a request for paymentcredentials, the request indicating an account from which payment for atransaction is to be made; looking up a payment token that correspondsto said account; generating dynamic expiry data and a dynamic tokenverification code; and responding to the request by transmitting thelooked-up payment token, the generated dynamic expiry data and thegenerated dynamic token verification code.
 14. The apparatus of claim13, wherein said transmitted payment token, dynamic expiry data anddynamic token verification code collectively uniquely correspond to saidtransaction.
 15. The apparatus of claim 14, wherein said generatingfunction includes a cryptographic process that has the looked-up paymenttoken as an input.
 16. The apparatus of claim 15, wherein saidcryptographic process has transaction data as another input, saidtransaction data corresponding to at least one attribute of saidtransaction.
 17. The apparatus of claim 13, wherein the processor isfurther operative, after performing said responding function, to receivea transaction authorization request message, the transactionauthorization request message containing said payment token, saiddynamic expiry data and said dynamic token verification code.
 18. Theapparatus of claim 17, wherein the processor is further operative, afterreceiving said transaction authorization request message, to verify saiddynamic expiry data and said dynamic token verification code.
 19. Theapparatus of claim 13, wherein the processor and the memory arecomponents of a payment services computer.
 20. The apparatus of claim13, wherein the indicated account is a deposit account maintained at abank.